home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / mint / l_0799 / 701 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  5.4 KB
  1. Subject: Re: Memory problems
  2. Date: Tue, 14 Dec 93 17:38:12 CET
  3. From: Juergen Lock <nox@jelal.north.de>
  4. In-Reply-To: <9312111941.AA22250@phlem.ph.kcl.ac.uk>; from "sjg@phlem.ph.kcl.ac.uk" at Dec 11, 93 7:41 pm
  5. Message-Id: <9312141638.AA00332@jelal.north.de>
  6.  
  7. sjg@phlem.ph.kcl.ac.uk writes:
  8.  
  9. > Is anyone else having the same problems with memory that I get running the
  10. > init suite of programs? 
  11. > 
  12. > When I run tcsh as the 'init' program from mint.cnf, I have something like 
  13. > 3.6Mb left over to play with. Not bad from the 4Mb it started from. The
  14. > problems come when I try the multi-user approach. When I log in having started:
  15. > 
  16. >     o init (and therefore update)
  17. >     o virtual consoles (4 of them - 4 getty's)
  18. >     o syslog
  19. >     o cron
  20. >     o lpd
  21. >     
  22. > and 1 tcsh on (say) vt01, I have 1.6Mb free(!!!).
  23.  
  24.  is that all free blocks (df /proc) or just the largest one? (Malloc(-1)...)
  25.  
  26. >  The memory usages of the 
  27. > programs (as given by ps) come to around 1.2Mb. That ought to give me over
  28. > 2.5Mb to play with. 
  29.  
  30.  also ps doesn't show everything, like kmalloc()d space (used by
  31. kernel, devices, filesystems...)  try ctrl-alt-f5, and (MiNT 1.09)
  32. ctrl-shift-alt-f5 (-> debug.c, mem.c, nalloc2.c).
  33. > 
  34. > Another thing is that when I run a tcsh on another terminal, and type 'mem'
  35. > the memory available has gone down (surprise :-), but when I press CTRL-D to
  36. > logout, and look at the memory available from the first terminal, it stays at
  37. > or about the level it was when 2 were running. Eventually I run out of memory.
  38.  
  39.  i don't know how tcsh's `mem' works, if its only the largest free block
  40. this doesn't have to be a real leak, maybe its `just' fragmentation...
  41. if you fix this, :)
  42.  
  43. Index: vcon.c
  44. @@ -86,15 +86,15 @@
  45.      if (cfd >= 0) {
  46.          /* try to uninstall gracefully... */
  47.          int opencnt = 0;
  48. -        char *vt00name=ttyname(cfd), *oldcname=ttyname(0), *s;
  49. +        char *vt00name, *oldcname, *s;
  50.          long vpgrp;
  51.  
  52.          /* /dev/vt00 might be renamed /dev/console... */
  53. -        if (vt00name && (s = strrchr (vt00name, '/')) &&
  54. +        if ((vt00name=ttyname(cfd)) && (s = strrchr (vt00name, '/')) &&
  55.              !strcmp (s, "/console"))
  56.              rename (vt00name, "u:/dev/vt00");
  57.          /* move original console device in place */
  58. -        if (oldcname && (s = strrchr (oldcname, '/')) &&
  59. +        if ((oldcname=ttyname(0)) && (s = strrchr (oldcname, '/')) &&
  60.              strcmp (s, "/console"))
  61.              rename (oldcname, "u:/dev/console");
  62.  
  63. you should be able to do a simple test:  login, go single user
  64. (SIGINT init, should shut down everything and give you a root sh,
  65. unless GEM was running... :( )  do a df /proc there, leave single user
  66. mode (exit sh) and do the same thing again.  i get the same result both
  67. times, if you don't maybe you can compare atrl-alt-f5 output and find
  68. the leak that way...
  69. > 
  70. > Presumably the memory used has not been reclaimed somewhere along the line, or
  71. > the free-memory management isn't working properly. Any fixes/ideas welocme :-)
  72.  
  73.  if your running 1.09, do you have the nalloc fixes installed?
  74.  
  75. ~Subject: nfree patch (memory fragmentation...)
  76. ~To: mint@terminator.rs.itd.umich.edu
  77. ~Date: Thu, 19 Aug 93 23:23:22 CES
  78. ~From: Juergen Lock <nox@jelal.north.de>
  79. ~X-Mailer: ELM [version 2.3/ST PL11]
  80. ~Message-Id: <9308192123.AA00114@jelal.north.de>
  81.  
  82. i just had it again, some memory chunk left in the middle of nowhere...
  83. looked again at the 1.09 diffs, hit ctrl-shift-alt-f5:
  84.  
  85. pid   4 (ksh): Arena at 1122A4 size 6000: free list:
  86. pid   4 (ksh):       112DC4 size        0
  87. pid   4 (ksh):       112E18 size        0
  88. pid   4 (ksh):       1133CA size        4
  89. pid   4 (ksh):       113468 size        8
  90. ...
  91. pid   4 (ksh): Arena at 1AC988 size 4000: free list:
  92. pid   4 (ksh):       1AC994 size     3FEC
  93.  
  94.  strange, a 4000 long area with 3fec free...  here's a patch :-)
  95.  
  96. --- nalloc2.c_    Tue Aug 17 18:36:30 1993
  97. +++ nalloc2.c    Thu Aug 19 21:46:12 1993
  98. @@ -239,7 +239,8 @@
  99.  
  100.      /* if, after coalescing, this arena is entirely free, Mfree it! */
  101.      if ((struct arena *)a->a_ffirst == a+1 && 
  102. -        (a->a_ffirst->b_size + sizeof(struct block)) == a->a_size) {
  103. +        (a->a_ffirst->b_size + sizeof(struct block) + sizeof(struct arena))
  104. +        == a->a_size && a != a_first) {
  105.          NALLOC_DEBUG('!');
  106.          *qa = a->a_next;
  107.  #if 1
  108.  
  109.  btw i later also found what looked like kmalloc'd pathnames of
  110. nonexisting files that the shell must have searched earlier...  is
  111. it tosfs that keeps them?  why? :-)
  112. ------------------------
  113. ~From: Andreas Schwab <schwab@issan.informatik.uni-dortmund.de>
  114. ~Date: Mon, 6 Sep 93 10:45:09 +0200
  115. ~Message-Id: <9309060845.AA20726@issan.informatik.uni-dortmund.de>
  116. ~Received: by issan.informatik.uni-dortmund.de id AA20726; Mon, 6 Sep 93 10:45:09 +0200
  117. ~Reply-To: schwab@ls5.informatik.uni-dortmund.de (Andreas Schwab)
  118. ~To: mint@atari.archive.umich.edu
  119. ~Subject: Bug in MiNT 1.09
  120.  
  121. There is a serious bug in kmalloc: when allocating a new arena for
  122. nalloc, the size passed to nalloc_add_arena is too big!
  123.  
  124. --- orig/util.c    Tue Aug 17 21:23:28 1993
  125. +++ util.c    Sat Sep  4 22:06:36 1993
  126. @@ -156,7 +156,7 @@
  127.          lp = (long *)m->loc;
  128.          *lp++ = (long)KMAGIC;
  129.          *lp++ = (long)m;
  130. -        nalloc_arena_add((void *)lp,KERMEM_SIZE);
  131. +        nalloc_arena_add((void *)lp,KERMEM_SIZE - 2*sizeof(long));
  132.          goto tryagain;
  133.          }
  134.      }
  135.  
  136.  and while your at it you could also increase the initial KERNEL_MEM
  137. (mem.h), i have it at 6*QUANTUM...
  138. > 
  139. > Simon.
  140.  may the source be with u :)
  141.     Juergen
  142. -- 
  143. J"urgen Lock / nox@jelal.north.de / UUCP: ..!uunet!unido!uniol!jelal!nox
  144.                                 ...ohne Gewehr
  145. PGP public key fingerprint =  8A 18 58 54 03 7B FC 12  1F 8B 63 C7 19 27 CF DA 
  146.